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Abstract. Family-based (lifted) data-flow analysis for Software Product 
Lines (SPLs) is capable of analyzing all valid products (variants) without 
generating any of them explicitly. It takes as input only the common code 
base, which encodes all variants of a SPL, and produces analysis results 
corresponding to all variants. However, the computational cost of the 
lifted analysis still depends inherently on the number of variants (which 
is exponential in the number of features, in the worst case). For a large 
number of features, the lifted analysis may be too costly or even infeasible. 
In this paper, we introduce variability abstractions dehned as Galois 
connections and use abstract interpretation as a formal method for the 
calculational-based derivation of approximate (abstracted) lifted analyses 
of SPL programs, which are sound by construction. Moreover, given an 
abstraction we define a syntactic transformation that translates any SPL 
program into an abstracted version of it, such that the analysis of the 
abstracted SPL coincides with the corresponding abstracted analysis of the 
original SPL. We implement the transformation in a tool, reconfigurator 
that works on Object-Oriented Java program families, and evaluate the 
practicality of this approach on three Java SPL benchmarks. 


1 Introduction and Motivation 

Software Product Lines (SPLs) are an effective strategy for developing and 
maintaining a family of related programs. Any valid program (variant) of an SPL 
is specified in terms of features selected. A feature is a distinctive aspect, quality, 
or characteristic from the problem-domain of a system. SPLs have been adopted 
by the industry because of improvements in productivity and time-to-market [7]. 
While there are many implementation strategies, many industrial product lines 
are implemented using annotative approaches such as conditional compilation; in 
particular, via the C-preprocessor #ifdef construct [15]. 

Recently, formal analysis and verification of SPLs have been a topic of 
considerable research (see [19] for a survey). The challenge is to develop analysis 
and verification techniques that work at the level of program families, rather 
than the level of individual programs. Given that the number of variants grows 
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exponentially with the number of features, the need for efficient analysis and 
verification techniques is essential. To address this, a number of so-called lifted 
techniques have emerged, essentially lifting existing analysis and verification 
techniques to work on program families, rather than on individual programs. 
This includes lifted type checking [14], lifted data-flow analysis [5,4], lifted model 
checking [6]. They are also known as family-based {variability-aware or feature- 
sensitive) techniques. Lifted techniques are capable of analyzing the entire code 
base (all variants at once), without having to explicitly generate and analyze 
all individual variants, one at a time. Also, lifted techniques are capable of 
pin-pointing errors directly in the product line, as opposed to reporting errors in 
an individual product derived from the SPL. 

There are two ways to speed up analyses: improving representation and in¬ 
creasing abstraction. The former has received considerable attention in the field 
of family-based analysis. In this paper, we investigate the latter. We consider a 
range of abstractions at the variability level that may tame the combinatorial 
explosion of configurations and reduce it to something more tractable by ma¬ 
nipulating the configuration space of a program. Such variability abstractions 
enable deliberate trading of precision for speed in family-based analyses, even 
turn infeasible analyses into feasible ones, while retaining an intimate relationship 
back to the original analysis (via the abstraction). 

We organize our variability abstractions in a calculus that provides conve¬ 
nient, modular, and compositional declarative specification of abstractions. We 
propose two basic abstraction operators {project and join) and two composi¬ 
tional abstraction operators {sequential composition and parallel composition). 
Each abstraction expresses a compromise between precision and speed in the 
induced abstracted analysis. We show how to apply each of these abstractions 
to data-flow lifted analyses, to extract (derive) their corresponding efficient and 
sound (correct) abstracted lifted analysis based on the calculational approach of 
abstract interpretation developed in [11]. Note that the approach is applicable to 
any analysis phrased as an abstract interpretation; in particular, it is not limited 
to data-flow analysis. 

We observe that for variability abstractions, analysis abstraction and analysis 
derivation commute. Figure 1 illustrates how analysis abstraction is classically 
undertaken and how we propose to optimize it. The top left corner shows a 
product line that we want to analyze. A lifted analyzer will take an SPL as input 
and derive a “lifted analysis” (rightward arrow). We can then run that lifted 
analysis (next rightward dashed arrow) and obtain our ^‘precise lifted analysis 
information”. (Note that for some analyzers, the phases derive analysis and 
subsequent run analysis may be so intertwined that they are not independently 
distinguishable.) Since running the analysis might be too slow or infeasible, we 
may decide to use abstraction to obtain a faster, although less precise analysis. 
Classically, an abstraction is applied to the derived analysis before it is run 
(middle arrow down) which, after an often long and complex process, produces 
an “abstracted lifted analysis”. When that analysis is subsequently run, it will 
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Fig. 1. Diagram illustrating the role and intended usage of the reconfigurator 
transformation. Instead of abstracting an already existing (or derived) lifted 
analysis, our transformation allows abstraction to be applied directly to the SPL. 
The resulting “abstracted SPL” can then be analyzed using existing techniques. 
The two paths from SPL to “abstracted lifted analysis” are guaranteed to produce 
the same abstracted lifted analysis. 


produce less precise analysis information, but it will do so faster than the original 
analysis (i.e., there is a precision vs. speed tradeojf). 

Interestingly, for lifted analyses and variability abstractions, the analysis 
abstraction (down) and derivation (right) commute and we may swap their order 
of application, as indicated by the short double leftward arrow in the center. The 
implications are quite significant. It means that variability abstractions can be 
applied before, and independently of, the subsequent analysis. This also means 
that the same variability abstractions might be applicable to all sorts of analyses 
that are specifiable via abstract interpretation; including, but not limited to: 
data-flow analysis [8], model checking [12], type systems [10] and testing [13]. 

We exploit this observation to define a stand-alone source-to-source trans¬ 
formation for programs with #ifdefs, implemented in a tool, reconfigurator. 
It takes an input SPL program and a variability abstraction and produces an 
abstracted SPL program such for which the subsequent lifted analysis agrees 
with “abstracted lifted analysis” of the original unabstracted SPL. Since the 
reconfigurator is based on a source-to-source transformation, and like a pre¬ 
processor it is essentially unaware of the programming language syntax, it can be 
used for any analysis. Many existing analysis methods that are unable to abstract 
variability benefit from this work instantly. Almost no extension or adaptation is 
required as the abstraction is applied to source code before analysis. 

We evaluate our approach by comparing analyses of a range of increasingly 
abstracted SPLs against their origins without abstraction, quantifying to what 
extent precision can be traded for speed in lifted analyses. 

In summary, the paper makes the following contributions: 

Cl: Variability abstraction as a method for trading precision for speed in family- 
based analysis (based on abstract interpretation); 
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C2: A calculus for modular specification of variability abstractions; 

C3: The observation that certain analysis derivations and analysis abstractions 
commute, meaning that variability abstractions can be applied directly on 
an SPL before (and independently of) subsequent lifted analysis; 

C4: A stand-alone transformation, reconfigurator, based on the above ideas; 

C5: An evaluation of the above ideas; in particular, an evaluation of the tradeoff 
between precision and speed in family-based analyses. 

We direct this work to program analysis and software engineering researchers. 
The method of variability abstractions (Cl—C3) is directed at designers of 
lifted analyses for product lines. They may use our insights to design improved 
abstracted analyses that appropriately trade precision for speed. Note that the 
ideas apply beyond the context of data-flow analyses (e.g., to model checking, type 
systems, verification, and testing). The reconfigurator (C4) and the evaluation 
lessons (C5) are relevant for software engineers working on preprocessor-based 
product lines and who would like to speed up existing analyzers. 

We proceed by introducing the basics of lifting analyses in Section 2. Section 3 
defines a calculus for specification of variability abstractions. Section! explains 
how to apply an abstraction to a lifted analysis. It uses constant propagation as 
an example. The re configurator is described in Sections along with correctness 
for our example analysis. Section 6 presents the evaluation on three Java Object- 
Oriented SPLs. Finally, we discuss the relation to other works and conclude. 

2 Program Families and Lifted Analyses 

In this section we summarize the prerequisites for presenting our work. We 
define features, eonfigurations, feature expressions, and a feature model which 
designates a set of valid configurations. Hereafter, we describe a simple imperative 
language IMP for writing program families. Finally, we briefly sketch a lifted 
constant propagation analysis for this language, formally derived in [17]. We focus 
on constant propagation for presentation purposes; our approach is generically 
applicable to any lifted analysis phrased as an abstract interpretation. 

Features, Configurations, and Feature Expressions. Let F = {Ai, ..., A„} be a 
finite set of features, each of which may be enabled or disabled in a particular 
program variant. A feature expression, FeatExp formula, is a propositional logic 
formula over F, defined inductively by: 

(fi ::= A e F I \ (pi A (p2 

A truth assignment or valuation is a mapping v assigning a truth value to 
all features. Every feature expression evaluates to some truth value under the 
valuation v. We say that p is valid, denoted as \= p, ii p evaluates to true for 
all valuations v. We say that p is satisfiable, denoted as sat((/3), if there exists a 
valuation v such that p evaluates to true under v. We say that the formula 9 is 
a semantic consequence of p, denoted as p \= 9, if for all satisfiable valuations v 
of p it follows that 9 evaluates to true under v. Otherwise, we have p^^ 9. 
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Feature Model. A feature model describes the set of valid configurations (variants) 
of a product line in terms of features and relationships among them. For our 
purposes a feature model can be equated to a propositional formula [2] , say 
ip & FeatExp, as the semantic aspects of feature models beyond the configuration 
semantics, are not relevant here. We write to denote the set of all valid 
configurations described by the feature model, 'll:; i.e., the set of all satisfiable 
valuations of '(/'• One satisfiable valuation v represents a valid configuration, and it 
can be also encoded as a conjunction of literals: ky = v{Ai) • Ai A • • • A v{An) ■ A„, 
where true ■ A = A and false ■ A = -^A, such that ky |= ip. The truth value 
of a feature in v indicates whether the given feature is enabled (included) or 
disabled (excluded) in the corresponding configuration. Let ky.^,... ,ky^ (1 < 
n < 2l®'l) represent all satisfiable valuations of ip expressed as formulas, then 
= {ky^, ..., ky^}. For example, the set of features, F = {A,B}, and the 
feature model, ip = AV B, yield the following set of valid configurations: = 

{A A B, A A ~^B, -^A A B}. 


The Programming Language. IMP is an extension of the imperative language 
IMP [21] often used in semantic studies. IMP adds a compile-time conditional 
statement for encoding multiple variants of a program. The new statement 
“#if {9) s” contains a feature expression 6 G FeatExp as a condition and a 
statement s that will be run, i.e. included in a variant, iff the condition 9 is 
satisfied by the corresponding configuration k € The abstract syntax of the 
language is given by the following grammar: 

s ::= skip |x:=e|s;s|ife then s else s j while e do s j #if (9) s 

e ::= n | x | e 0 e 

where n ranges over integers, x ranges over variable names Var, and 0 over 
binary arithmetic operators. The set of all generated statements s (respectively 
expressions e) is denoted by Stm (respectively Exp). Notice that IMP is only 
used for presentational purposes as a well established minimal language. Still, 
the introduced methodology is not limited to IMP or its features. In fact, we 
evaluate our approach on Object-Oriented program families written in Java. 

The semantics of IMP has two stages. First, a preprocessor takes as input 
an IMP program and a configuration k G K^, and outputs a variant, i.e. an 
IMP program without #if-s, corresponding to k. All “#if (9) s” statements are 
appropriately resolved in the generated valid product, i.e. s is included in it iff 
k \= 9. Then, the obtained variant is executed (compiled) using the standard 
IMP semantics [21]. 


Constant Propagation Analysis. In the context of IMP lifting means taking a 
static analysis that works on IMP programs, and transforming it into an analysis 
that works on IMP programs, without preprocessing them (so on all the variants 
simultaneously). The lifted constant propagation analysis for IMP was derived 
in [17]. We first define a constant propagation lattice {Const, Ec), whose partial 
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ordering Qc is given by: 



In this domain T c indicates a non-constant value, and _Lc indicates unanalyzed 
information. All other elements indicate constant values. The partial ordering 
□c induces a least upper bound, Uc, and a greatest lower bound operator, flc, 
on the lattice elements. For example, we have 0 Uc 1 = Tc, Tc He 1 = 1, etc. 

The constant propagation analysis is given in terms of abstract constant 
propagation stores, denoted by a, essentially mappings of variables to elements 
of Const. Thus a(x) informs whether the variable x is a constant, and, in this 
case, what is its value. We write A = Var —> Const meaning the domain of 
all constant propagation stores. Since Const is a complete lattice then so is 
(A, Ua) Ua, Ha, Ta, Ta) obtained by point-wise lifting [21]. For example, for 
a, a' G A we have a Ua a' iff Vx G Var, a(x) Cc a'(x). We omit the subscripts C 
and A whenever they are clear in context. 

Lifted Constant Propagation Analysis. For the lifted constant propagation anal¬ 
ysis, we work with the lifted property domain , C, U, □, _L, T), where 
is shorthand for the |IK,|,|-fold product IlfcGKY, Iasi's is one separate copy 

of A for each valid configuration of . The ordering t is lifted configuration- 
wise; i.e., for a,a' G we have a t a' =def T^k{d) Ea 7rfc(a') for all k G K,p. 
Here selects the component of a tuple. Similarly, we lift configuration- 
wise all other elements of the complete lattice A, obtaining LJ,n,_L,T. E.g., 
T = ri/ceKy, Ta = (Ta, ■ • ■, Ta). 

The lifted analysis -4|s] should be a function from A*’^ to A'*^’^. However, 
using a tuple of jlK^j independent simple functions of type A —>■ A is sufficient. 
Thus, the lifted analysis is given by the function A|s] : (A —>■ A)'*^'/’, which 
represents a tuple of [K^j functions of type A —> A. The fc-th component of 
^|s] defines the analysis corresponding to the valid configuration described by 
the formula k. Thus, an analysis -4|s] transforms a lifted store, d G into 
another lifted store of the same type. For simplicity, we overload the A-abstraction 
notation, so creating a tuple of functions looks like a function on tuples: we write 
^d.l\i,^^fk{TTk{d)) to mean IlfcGKSimilarly, ii f : {A ^ A)^ and 
d G A®^, then we write /(a) to mean nfceK^fc(/)(^fc(®))- 

The equations for lifted analysis Al|s] : (A —>• A)’^’^ and Al'|e] : (A —>■ Const)^'i' 
that analyse all valid configurations simultaneously are given in Fig 2. They are 
systematically derived in [17] by following the steps of the calculational approach 
to abstract interpretation [11]: define collecting semantics, specify a series of 
Galois connections and compose them with the collecting semantics to obtain the 
resulting analysis, which is thus sound (correct) by construction. Monotonicity 
of Al|s] and Al'|e] was shown in [17] as well. 
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^Iskip] 
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^[so : si] 
w4|if e then sq else si| 
^|while e do s| 
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Fig. 2. Definitions of y^|s] : (A —)■ and A'\e\ : (A —>■ Constf"'*'. 


The (transfer) function ^|s] captures the effect of analysing the statement s 
in an input store a by computing an output store a'. For the skip statement, the 
analysis function is an identity on lifted stores. For the assignment statement, 
X ; = e, the value of variable x is updated in every component of the input store 
a by the value of the expression e evaluated in the corresponding component of 
a. The if case results in the least upper bound (join) of the effects from the 
two corresponding branches, and it abstracts away the analysis information at 
the guard (condition) point. For the while statement, we compute the least 
fixed point of a functional^ in order to capture the effect of running all possible 
iterations of the while loop. This fixed point exists and is computable by Kleene’s 
fixed point theorem, since the functional is a monotone function over complete 
lattice with finite height [17,8]. For the #if {&) s statement, we check for each 
valid configuration k ^ whether the feature constraint 0 is satisfied and, if so, it 
updates the corresponding component of the input store by the effect of evaluating 
the statement s. Otherwise, the corresponding component of the store is not 
updated. The function A' |e] describes the result of evaluating the expression e in 
a lifted store. Note that, for each binary operator 0, we define the corresponding 


^ The functional of the while rule is: Xa. a U $(A|[s]| a). 

^ Since any k G K,/, is a valuation, we have that k ^ 6 and k \= —^9 are equivalent for 
any 6 G FeatExp. 
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constant propagation operator 0, which operates on values from Const, as follows: 


{ _L if no = -L V z;! = _L 
n if no = no A ni = ni, where n = no 0 ni 
T otherwise 

We lift the above operation configuration-wise, and in this way obtain a new 
operation 0 on tuples of Const values. 

Example 1. Consider the IMP program 

X := 0; 

#if (A) X := X 0 1; 

#if {B) X := 1 

with the set = {A A B,AA -^B, ^A A B}. By using the rules of Fig. 2, we can 
calculate for a store in which x is uninitialized, i.e. it has the value T. We 

assume a convention here that the first component of the store corresponds to 
configuration A A B, the second to >1 A ^B, and the third to -^A A B. We write 

Oq oY when M|s]ao = oT. We have: 

([x^T],[x^T],[x^T]) ([x^0],[x^0],[x^0]) 

After evaluating ^i, the variable x has the constant value 1 for all valid configu¬ 
rations. Observe that in the above lifted stores many components are the same, 
i.e. many configurations have equivalent analysis information. Such lifted stores 
can be more compactly represented using sharing (e.g., bit vectors or formulae), 
which in effect will result in more efficient implementation of the lifted analysis. 

Let S 2 be a program obtained from Si, such that #if (B) x := 1 is replaced 
with #if (B) X := X — 1. Then, we have: 

M|5'2l([xH>T],[xH>T],[xH>T]) = ([xi-^0],[xH>l],[xH>-l]) 

We will use programs Si and S 2 as running examples throughout the paper. □ 


3 Variability Abstractions 

When the set of configurations is large, calculations on the property domain 
become expensive, even if using symbolic representations or sharing to avoid 
direct storage of |K,^|-sized tuples as done in [5]. We want to replace with 
a smaller domain obtained by abstraction and perform an approximate, but 
feasible, lifted analysis. 



3.1 Basic Abstractions 


We describe a compositional way of constructing abstractions over the domain 
where K represents an arbitrary set of valid configurations, using two basic 
constructors, join and projection, along with a sequential and parallel composition 
of abstractions. The set of abstractions Abs is generated by the following grammar: 

a ::= 0:^°™ | | a o a | a 0 a (1) 

where ip G Feat Exp. Below we define the constructors and motivate them with 
examples. For readability, we use the constant propagation lattice A however 
the results hold for any complete lattice. 


Join. Consider the following scenario. An analysis is run interactively, while a 
developer is typing in a development environment. The analysis finds simple 
errors and warnings. In this scenario, the analysis must be fast and it should 
consider all legal configurations K. It is not problematic if some spurious errors 
are introduced, since, like previously, a more thorough analysis is run regularly. 
Here, the precision with respect to configurations can be reduced by confounding 
the control-flow of all the products, obtaining an analysis that runs as if it was 
analyzing a single product, but involving code variants that participate in all 
products. 

The join abstraction gathers the information about all valid configurations 
fc G K into one value of A. We formulate the abstraction : A'*^ —> 

and the concretization function —>• A'*^ as follows: 

aJ°“(a) = (IJfegK^fe(a)) and 7J°“(a) = “ (2) 

fcGK 


We overload abstraction names (a) to apply not only to domain elements but 
also to sets of features, sets of configurations, and, later, to program code. The 
new set of valid configurations is Q:j°“(IK) = {V^gk Thus, we have only one 
valid configuration denoted by the formula VfcGK Observe that this means that 
the obtained abstract domain is effectively A^, which is isomorphic to A. The 
proposed abstraction-concretization pair is a Galois connection, which means that 
it can be used to construct analyses using calculational abstract interpretation: 


Theorem 1. 


(A*^, t) 



(Aa''‘”"(K), □) jg ^ Galois connection ^ 


Example 2. Let us return to the scenario of using join for improving analysis 
performance. Assume that the feature model is given hy ip = AV B with valid 
configurations = {AAB,AA -^B, ^A AB}. Now, the final stores we obtain by 

^ (T, <l) ^ {M,<m) is a Galois connection between complete lattices L and M 

iff a and 7 are total functions that satisfy: a{l) <m m I <l yim) for all 

I £ L,m £ M. 

The proofs of all theorems in this section can be found in App. A. 
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analyzing programs 5'i and S 2 from Example 1 are dsi = ([xi—>■!]) 
and as 2 = ([x > 0],[x 1 —> l],[x 1 —)■ — 1]). Applying the join abstraction we obtain 
Q;j°™(dsi) = ([x 1]) and Q:j°™(ds 2 ) = ([^ T]). In both cases the state 

representation has been significantly decreased. In the former case, the abstraction 
promptly notices that x is a constant regardless of the configuration. In the latter 
case, the abstraction looses precision by saying that x is not a constant in general, 
even if it was a constant in each of the configurations considered. We will continue 
using stores asi and 053 in the subsequent examples. □ 


Projection. In industrial practice the number of products actually deployed 
is often only a small subset of IK[3]. In such case, analyzing all legal (valid) 
configurations seems unnecessary, and performance of analyses can be improved 
by abstracting many products away. This is achieved by a configuration projection, 
which removes configurations that do not satisfy a given constraint, for instance 
a disjunction of product configurations of interest. Projection can be helpful in 
other similar scenarios; for instance, to parallelize the analysis—by partitioning 
the product space using project and analyzing each partition separately. 

Let (/? be a formula over feature names. We define a projection abstraction 
mapping into the domain which preserves only the values cor¬ 

responding to configurations from K that satisfy p. The information about 
configurations violating p is disregarded. The abstraction and concretization 
functions between A'’^ and are defined as follows: 


= nfcGK.fehv ^fc(a) 

17rfc(a') \ik\= (f 

IT if fc ^ V? 


7r'(«') = n 


k£K 


( 3 ) 

( 4 ) 


The new set of configurations is aP‘'°j(IK) = {fc € K | fc |= </?}. Naturally, we also 
have a Galois connection here: 


Theorem 2. (A*^, t) ^ (A°‘r is a Galois connection. 


Notice that a})™;) is the identity function, since k \= true for all fc G K. On the 
other hand afaise is the coarsest collapsing abstraction that maps any tuple into 
an empty one, since k ^ false, for all k. 


Example 3. Let us revisit our scenario, where a set of deployed configurations 
is much smaller than the set of configurations defined by the feature model 
'0. Let us consider the store with the set of valid configurations K,;, from 
Example 2. The set of deployed products is defined by formula ip = A (so all 
possible programs with feature A are marketed). By definition of projection 
(3), we have: (ds^) = {TTAAB{as 2 ),'^AA^B{as 2 )) = ([x 0], [x 1]), and 

«T(«&) = (^ ^AABias-i)) = ([x'->'—!])• The state representation is effectively 
decreased to two, respectively one, components. □ 
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An attentive reader, might discount the idea of the projection abstraction as 
being overly heavy. In the end, it appears to be equivalent to running the original 
analysis, just with a strengthened feature model {ip ^ ‘P)- However, as we shall 
see in the subsequent developments, projection is indeed useful. Thanks to the 
composition operators it can enter intricate scenarios, which cannot be expressed 
using a simple strengthening of a global feature model. 

Sequential Composition. We use composition to build complex abstractions out 
of the basic ones, which also allows us to keep the number of operators in the 
framework and in the implementation low. 

Recall that a composition of two Galois connections is also a Galois connection 
[9]. Let (A'^,t) (A“iW,C) and (A“iW,t) (A“A«i(k))^ 

two Galois connections. Then, we define their composition as (A'*^, t) < _ - 

0i200L\ 

(A(“ 2 °“i)(k),C), where 

(a 2 o ai)(a) = a 2 (ai(a)) and o 72)(a') = 71 ( 72 ( 0 ')) (5) 

for a £ A'’^ and a' £ Also (012 o ai)(K) = q; 2 (cii(K)). 

Example 4- Now consider the process of deriving an analysis, which only considers 
products actually deployed described by a formula (p (see previous example), but 
which should trade precision for speed, by confounding their execution. Such an 
analysis is derived using the composed abstraction: o aP^L 

Let <p = A. Gonfigurations AAB and AA^B satisfy p, whereas is satisfied 
only by ^A A B. We have: Q:j“" o Q:P''°J(asJ = (7rAAB(as2) LI 7r^A-B(as2)) = 
([xH>T]) and o qP^^( 05 J = ('^^AAB(as 2 )) = ([xH>-l]). □ 

Parallel Composition. Consider a product line where two disjoint groups of 
products share the same code base: one group is correctness critical, the other 
comprises correctness non-critical products. The former should be analyzed with 
highest precision possible to obtain the most precise analysis results, the latter can 
be analyzed faster. We can set up such analyses by using a projection abstraction 
to analyze the correctness critical group precisely, and the join abstraction to 
analyze the non-critical group. However running the analyses twice, ignores the 
fact that the code is shared between the groups. We can combine two separate 
analyses by creating a compound abstraction: a product of the two. The product 
abstraction will correspond exactly to executing the projection on the correctness 
critical products, and join on the non-critical ones. But since the product creates 
a single Galois connection of the two, it can be used to derive an analysis which 
will deliver this in a single run, which is more efficient overall, due to reuse of 
the states explored. 

Galois connections (Ai^, t) t=^(A“i(K) t) and (A*t) (A“ 2 (K)t) 

over the same domain A'*^ can be cornposed into one that combines tlie abstraction 
results "side-by-side". The result is a new compound abstraction, ai G) 02 , of the 
domain A* obtained by applying the two simpler abstractions in parallel. The 
parallel composition of abstractions is defined using a direct tensor product. For 
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the resulting Galois connection, we have ai 0 a 2 (IK) = ai(K) U 02 (K)- Given 
Oi G and 02 G A“ 2 W, we first define Oi x 02 G q;i(K) U 02 (K) as: 

r7rfe(di) if A: G ai(K) \ a2(lK) 

01 X 02 = < 7rfe(di) U 71 ^( 02 ) if A: G ai(K) n q;2(K) (6) 

feGai(K)uaAK) [7rfe(a2) if A: G 02 (K) \ Oi (K) 

The direct tensor product is given as (A®^, t) j'_^(ai®a 2 )(K)^ where 

ai0Q:2 

(oi G a 2 )(a) = oi(a) X 02(0) ( 7 ) 

(71 G 72)(a') = 7i(7>‘c<i(K)(a')) n 72(7ra2(K)(a')) , where (8) 

’Gi(K)(a')=nfeGai(K)’"fc(«') and 7G2(K)(a') =nfcGa 2 (K)^fc(a'), for a'GAfoi®“=)« 

Theorem 3. (A®^, t) < ^_^(Qi®a 2 )(K)^ ^ Galois connection. 

01002 

Example 5. Let us assume that for products with feature A we need precise 
analysis results, and for products without this feature we do not need so precise 
results. We are interested in analyzing products with A thoroughly, while the 
analysis of the products without A can be speeded up. To this end we build the 
following abstraction: 0 o aP™-’). □ 


3.2 Derived Abstractions 

We shall now discuss three more abstractions that can be derived from the above 
basic constructors. 


Join-Project. Recall the construction of Example 4, where we combined projection 
with a join in order to confound a subset of legal configurations. This pattern 
has occurred so often in our exercises that we introduced a syntactic sugar for 
it. For a formula (p over features, the abstraction 0 :^“ gathers the information 
about all valid configurations A; G IK that satisfy :/?, i.e. A; |= tp, into one value of 
A, whereas the information about all other valid configurations A; G K that do 
not satisfy p is disregarded. We define 

<" = o ap and 7 ^" = 7 ^ o (9) 

_proj join 

where we have that (A*^, t) . 7 and ..7 

Q,proi ^join 

(Afo^ oqp Galois connections. Now the compositions in Example 4 

can be written simply as and 
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Ignoring features. Consider a scenario, where a configurable third-party com¬ 
ponent is integrated into a product line. The code base is large, and a static 
analysis does not scale to this size. In a compile-analyze-test cycle errors appear 
most often in the newly written code, and are thus relatively little influenced by 
how the features of the third party component are configured. Lowering precision 
on analyzing external components can allow finding errors faster. This scenario 
can be realized using a feature projection, which simplifies feature domains by 
confounding executions differing only on uninteresting features. 

Before defining feature projection, let us consider a simpler case of ignoring 
a single feature A S F that is not directly relevant for current analysis. The 
ignore feature abstraction merges any configurations that only differ with re¬ 
gard to A, and are identical with regard to remaining features, F\{A}. We 
write for a formula obtained by eliminating variable A from ip. The ac¬ 
tual method of variable elimination is insignificant, as we assume all equivalent 
formulas as identical in this paper. The new set of configurations is given by 
^fignore^jg-^ _ {k \ k' G {fc\yi | k G K}}. The abstraction : 

—>■ A“a* and concretization functions : A“^* —>■ A®^ are: 

(“) nfc'GaY“°'’TK) UfceK.fchfc' (10) 

= nfeGK’^fe'(«') ^ik\=k' (11) 


It turns out that ignoring features can be derived from the above basic 
abstractions as shown in the following theorem: 

Theorem 4. Let q:^®"°'^®(K) = {k [,..., k!^}. Then: 


^fignore ^ ^join , 


. loin 


and ' 




Example 6. We consider the lifted store with = {A A B, A A -^AAB}. 
Then, we have = {(A A i?) V (^A A B), A A ^5} and a^®“”®(as 2 ) = 

{■^AABidsJ LI T^^AAB{ds 2 ),TTAA^B{dsJ) = ([xT], [xi-A 1]). On the other hand, 
we have q;^®"“®(IK^) = {(A A B) V (A A ^B),^A A B} and Q:^®“”®(as 2 ) = 
(7rAAB(as2) U 7rAA^B(as2),7’‘^AAB(aS2 )) = ([xi-aT], [xi-A-1]). □ 


Feature Projection. Now, if we need to ignore a larger number of features (say 
features outside a certain component of interest), we can do it using a feature 
projection operator which simply ignores a set of features {Ai,..., A*,} C F: 


fproj _ fignore 

{Ax,...,Au} ~ 


fignore 

■°^aI 


and 


fproi fignore fignore 

7fA,:..,A,} = 7 a: °---°7a. 


It follows from the theorems of Section 3.1 that all the derived pairs of abstraction- 
concretization are Galois connections. 


4 Abstracting Lifted Analyses 

We will now demonstrate how to derive abstracted lifted analyses using the 
operators of Section 3, using the case of constant propagation for IMP programs 
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(by def. of o) 


(aoylpif ( 9 ) s] o7)(d) = Q(^|#if ( 6 ) s](7(d))) = 

= a[ TT itk\=e \ 

( 7rfe/(a(^|[sl7(d))) 

- n “I LJ7rfc/(a(^|[sl|7(d))) 

('Kk'{T)als\d) iik '\=6 

“ rr l''^k'id) ^’’^k'(T^afsjd) if sat(fc'Ad) A sat(fc'A-10) 
fc' 6 °^(Kv.)[ 7 rfc/(d) iffc'l=^d 

(by IH and a o 7 reductive) 

= ©a[#if (d) s] d 


(def of A in Fig. 2) 

if k' 1= d 

if sat(/c'Ad) A sat (fc'A-id) 
if k' \= -nd 

(Lemma 2 , App. C) 


Fig. 3. Calculational derivation of I?a|#if (0) s], the abstraction of yi|#if (0) s]. 
The ‘reductive’ property of all Galois connections is (a o 7 )(d) O d for all d. 

as an example. Recall that this analysis has been specified by: 1) the domain 
2 ) the statement transfer function yl|s] : (A —>■ A)'*^’tj and 3) the expression 
evaluation function .4'|e] : (A —>■ Const)^'!’. Let (A’*^’'', t) (A“(’‘^’t)^ □) be a 

Galois connection constructed using the abstractions presented in Section 3. We 
will also write (a, 7 ) € Abs to denote a Galois connection obtained in such way. 

Any function / defined on the concrete domain of a Galois connection can 
be abstracted to work on the abstract domain by applying concretization to its 
argument and an abstraction to its value, i.e. by the function F = a o / o 7 , 
where o denotes the usual composition of functions. In fact, any monotone over¬ 
approximation of the composition a o / o 7 is sufficient for a sound analysis. 
Even fixed points can be transferred from a concrete to an abstract domain of a 
Galois connection. If both domains are complete lattices and / is a monotone 
function on the concrete domain, then by the fixed point transfer theorem (FPT 
for short) [8]: Q:(lfp/) C IfpF C IfpF^. Here F = a o / o 7 and F# is some 
monotone, conservative orier-approximation of F, i.e. F C F^. The calculational 
approach to abstract interpretation [ 11 ] used in this work, advocates simple 
algebraic manipulation to obtain a direct expression for the function F (if it 
exists) or for an over-approximation F^. 

In our case, for any lifted store d G A'^’'’, we calculate an abstracted lifted 
store by a{a) = d G Now, we use a Galois connection to derive an 

over-approximation of a o yl|s] o 7 obtaining a new abstracted statement transfer 
function Fq,|s] : (A —>■ Similarly, one can derive an abstracted analysis 

for expressions F'^le], approximating a o ^'|e] o 7 . These approximations are 
derived using structural induction on statements (respectively on expressions). 
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(by def. of o, and A' in Fig. 2 ) 


(q o A'leo © ei] o 7)(d) 

= “( n ^fe(-^'Ieol7(rf))®7rfe(^'|[ei]7(d))) 

= 7rfc'(a(.4'|eol7(d) ©7l'|ei]7((i))) (by def. of tt*;, ©, and a) 

£ 7rfe/(a(7l'|eol7(d)) ©a(7l'|ei]l7(d))) (by Lemma 3 in App. C) 

k' £oi{K^) 

£ 7rfe/(I?'Q|[eo]d) ©7rfe/(F>'Q|ei]d) (by IH, and def. of tt^/ and ©) 

k' Goi(K^ ) 

= Valeo © ei]d 


Fig. 4. Calculational derivation of I?c«[eo 0 ei]. 

in a process that resembles a simple algebraic calculation, deceivingly akin to 
equation reasoning. 

Let us consider the derivation steps for the static conditional statement 
(#if ( 6 *) s) in detail. Our inductive hypothesis (IH) is that for statements s' 
that are structurally smaller than (#if {9) s) the (yet-to-be-calculated) I?a[s'] 
soundly approximates ao^|s']o 7 , formally: aoy^|s']o 7 C I?q|s']. The derivation 
in Fig. 3 begins with composing the concretization and abstraction functions 
with the concrete transfer function and then proceeds by expanding definitions. 
An (inner) induction on the structure of the abstraction a follows, delegated to 
the Appendix for brevity. In the last step we apply the inductive hypothesis, to 
obtain a closed representation independent of A. This representation, just before 
the final equality, is the newly obtained (calculated) definition of the abstracted 
analysis 'Da ■ Interestingly, the derivation is independent of the structure of the 
abstraction a, so this form works for any abstraction specified using our operators. 
We give a sketch of derivational steps for cq © ei in Fig. 4. 

The derivations for other cases are similar and can be found in App. B. 
The process results in the definitions of T’ct|sl and ©’'aje] presented in Fig. 5. 
Monotonicity of I?q|s] and P'^le] is shown in App. D. Soundness of the ab¬ 
stracted analysis follows by construction; more precisely the complete calculation 
constitutes an inductive proof of the following theorem: 

Theorem 5 (Soundness of Abstracted Analysis). 

(i) Ve G Ex-p, {a,^) G Abs, d G : a o A'\e\ o 7 (d) t d 

(a) Vs G Stm, (a, 7 ) G Ahs, d G : a o A |s] o 7 (d) IZ D a\s\d 

Example 7. Consider the program Si from Example 1, with = {A A B, A A 
-^A A B}. We calculate Da^ [S'!] for Oi = Following the rules of Fig. 5, 

we obtain the following confounded abstract execution off all configurations 
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'Da [[skipl = \d. d 

■D„|x := e] = Ad. (irfc/(d))[x M- 


(^k'id))lx^ TT^iiTi'aMd)] 


fe'eo(iK^) 

■Dolso ; si] = X>o[si] o X)„[sol 
Dalif e then sq else si] — Xd. Da |so|rf U Dalsijd 

Da [while e do s| — IfpA^. Xd. d U ^{Da [s] d) 



if k' 1 ^ e 

if sat(fc^ A0) A sat(/c^A—10) 
if k' 1^ 



X>'c|x] = Ad. Tvy{d)(x) 


k'€a(K^) 


■D'aleo ® eil = Ad. tt;,/('D'„ [Ieo]d) ® ttj.; (X)' 


® 7rfc'('D'c,Iei]d) 


fc'eo(K^) 


Fig. 5. Definitions of I?q|s] : (A — >■ and I?A[e] : (A —>■ Const)°‘^^'i'\ 

containing the feature A: 



X„J#if(A)x:=x+ll 


X<,iI#if(S)x: = l] 




In the last step we used (i?) x := l]([x i-® 1]) = ([x i-> 1]) U f ai [x := 

l]([x i-> 1]) since ((A A i?) V (A A ^B)) A B and ((A A B) V (A A ^B)) A ^B are 
both satisfiable. The final result shows that the value of x is the constant 1 for 
every configuration that satisfies A. On the other hand, for the program S 2 and 
the same abstraction we obtain I?qj|S' 2 ]([x H>T]) = ([x H>T]), so the value of x 
is lost (approximated) by Va^. □ 

We may implement the abstracted analysis in Fig. 5 directly by using Kleene’s 
fixed point theorem to calculate fixed points of loops iteratively. But, we can also 
extract corresponding data-flow equations, and then apply the known iterative 
algorithms to calculate fixed-point solutions. We assume that the individual 
statements are uniquely labelled with labels Given an abstraction a, for each 
statement we generate two abstracted stores which 

describe the input and output abstract store for all configurations before and after 
executing the statement . They are related with the definitions for abstracted 
analysis Va given in Fig. 5 as follows: for each statement s the input store 
is substituted for the parameter d, and the output store |s^]^ for the value of 
the corresponding function. Some variability dependent data-flow equations are 
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Vfc' e a(K^) : irfc/([x ■.= ='^fc'(Ix ■= e^01|^)“ [x >->■ Ie'^°||x ■.= 

f ’"fc'ds^”]^) iffc'|=e 

Vfc' g a(K^) : 7rfc/(|#if'^ (S) («) ^ ’r^/ds^o]^) if sat(k'A0)Asat(k'A^ff) 

[ iffe'h^e 

Vfc' e a(Ky,): 'ffc/(Is^°l?) = ''''fc/(|#if^ (6) 'f sat(fc' A 6) 


Fig. 6. Selected data-flow equations for abstracted constant propagation. 


given in Fig 6. The complete list of data-flow equations along with the proof of 
their soundness can be found in App. E. 


5 Variability Abstraction with Syntactic Transformation 

The analyses A and T^a can be implemented either directly by using definitions 
of Figs. 2 and 5, or by extracting the corresponding data-flow equations. An 
entirely different way to implement Pq is to execute the abstraction on the 
source program, before running the analysis, and then running the previously 
existing analysis A on this transformed program. We take this route as it allows 
to completely reuse the effort invested in designing and implementing A. 

Any IMP program s with sets of features F and valid configurations K is 
translated into a corresponding abstract program a(s) with corresponding set 
of features a(F) and set of valid configurations q;(IK). We define the translation 
recursively over the structure of a. All statements other than #if are copied. 
For example, a(skip) = skip and a(so ; si) = a(so) ; Q!(si). We discuss the 
rewrites for #if statements below. 

In the rewrite, we associate a fresh feature name Z ^ ¥, with every join 
abstraction q; 1°™ (consequently written The new feature Z is an abstract 

name (renaming) of the compound formula VfcgK denotes the single valid 
configuration obtained from The new feature name is used to simplify 

conditions in the transformed code. The rewrite is defined as follows: 


'(F) = {Zj, 


'(K) = {Z} 


f#if (Z) a)°'"(s) 


if VfcPK ^ h ^ 


»j°'"(#if (0) s) = (^) lub(Q:^^?(s),skip) if sat(VfcgK^^^)^ 

sat(VfeGK^'^^^) 
’ (^) if VfcGK k 1= ^0 


Aif (^Z) 


In effect of applying the transformation to any program s we obtain 

a single variant program, i.e. a SPL with only one valid product where the 
feature Z is enabled. It can be analyzed with existing single-program analyses. 
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Note that it enables performing family-based analyses with implementations 
of single-program analyses, albeit with loss of precision. The newly introduced 
statement lub(so,Si) represents the least upper bound (join) of the results 
obtained by executing sg and si. This is the only language-dependent aspect 
of reconfigurator. It can have different implementations depending on the 
programming language and the analysis we work with. In our case, we exploit 
the fact that .4|if e then sg else si] ignores the branching condition (cf. Fig. 2) 
and use lub(sg,si) = if (n) then sg else si for some fixed integer n. Finally, 
observe that #if {^Z) is equivalent to skip, however it is useful to keep 

the statement in the program, which makes it easy to merge programs when we 
use compound abstractions (below). 

The rewrite for projection only changes the set of legal configurations: 

ap(F)=F, aP™j(K) = {fcGK|fch<^}, ap(#if (0) s) = #if (0) ap(s) 

Note that the general scheme for the basic rewrites of #if statements can 
be summarized as a(#if (0) s) = #if {a{9)) d(s, 0), where a are functions 
transforming the condition 9 and the statement s. It is easy to extract a{9) and 
d(s, 9) from the above rewrites for s-nd cy.^°K We will use them in defining 
transformations for binary operators. 

Now, for the case of parallel composition ai®a 2 , recall that the set Q;i(g)Q; 2 (K) 
is the union of Q!i(K) and a 2 (IK). However in the rewrite semantics, we are 
sometimes modifying the set of features. If ai(F) ^ 02 (F) then some of valid 
configurations in q;i(K) U 02 (K) will not assign truth values to all features in 
q;i(F) Ua 2 (F). To take a meaningful union of configurations, we need to first unify 
their alphabets. To achieve this aim, each valid configuration can be extended by 
information that the missing features are excluded from it (negated). Now the 
rewrite rules for parallel composition are given by: 

q:i(8)q:2(F) =ai(F) U a2(F) 

ai(g)a2(]K) = {fci A I *1 e a:i(IK)} U {^2 A 1 ^2 G a2(IK)} 

f #if (cFi"(6*) V 02 ( 0 )) ai{s,9) if Qq(S) d) = 02 ( 3 , 0) 
oi ® a2(#if {9) s) = % 

[Q;i(#if {9) s);a 2 (#if {9) s) otherwise 

Observe that the second case of the parallel composition transformation can 
only appear if the second case of a join transformation has been used somewhere 
in recursive rewriting of s (perhaps deep). All the other rewrites leave s intact. 
However, in such case the branches have disjoint feature alphabets, as every join 
is using a fresh feature name as parameter. This ensures that only one of the 
sequenced copies of s, Qq(s, 0) and q^(s,0), will actually be executed (and the 
other will amount to skip) in any given configuration of the product. 

For sequential composition of abstractions 0200:1 we use the following rewrites: 
02 o ai(F) = a 2 (ai(F)), 02 o ai(K) = Q; 2 (ai(K)) and 02 o ai(#if [9) s) = 
#if (d^(al(0))) d^(dl(s,0),^(0)). 
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s : IMP 
(SPL) 


derive analysis 


a(s) : IMP 
(abstracted SPL) 


derive analysis 


^|s] : (A ->• A)*’#' 

(lifted analysis) 


: (A^ Af-^ 

(abstracted lifted analysis) 


Fig. 7. Illustration of derive vs abstract: I?a|s] = -4|q!(s)]. 


Example 8. Consider the program S[: #if {A) x := x + 1; #if {B) x := 1 
with F = {A, B}, ij) = Ay B, and = {A A B, A A ^B, ^A A B}. Then 

o = #if [Z) X := X + 1; #if {Z) lub(x := 1, skip) (12) 

The set of valid configurations after projection is changed to {AAB, AA^B}, and 
after join again to just {Z}. The obtained program has only one configuration, 
the one that satisfies Z. The projection does not change the statements of 
the program. The join rewrite however, simplifies the first #if (it is statically 
determined; cf. the first case of transformation), and joins the second 

statement with skip as it is unknown whether it will be executed or not, in 
the lack of information about the assignment to B in the abstracted program. 
Note that since Z is the only one valid configuration, the obtained program 
is equivalent to: x := x + 1 ; lub(x := l,skip). Similarly, we can calculate: 
o Q:^™^(S'j) = #if (Z) lub(x := X + 1, skip); #if (Z) x := 1. 

Now consider ((a-!^™oa(^''°^)(g)a^''°^)(S'(). The new set of features is {Z, A, B}. 
The subset {A,B} is retained from the right projection component, and {Z} comes 
from the left join-project component. After extending the configurations of both 
components with negations of absent feature names we get the following set 
of valid configurations: K' = {Z A ^A A ^B, ^Z A A A B, ^Z A ^A A B}. The 
result of the left join-project operand is the program (12), and the right rewrite 
(projection) never changes the statements, so its result is identical to Aj. Thus 
we are composing programs (12) and Aj using the parallel composition rewrites. 
Then ((aP™j o a^^") ® aP™j)(5() is: 

#if {Z y A) X := X -|- 1; #if (Z) lub(x := 1, skip); #if {B) x := 1 

The first #if has been unified using the first case of the transformation for 0, 
and the second #if is transformed into two copies of the statement with different 
guards, using the second case of the rewrite definition. For any legal configuration 
in K' at most one of them does not reduce to skip. □ 

Now the analysis Al|a(s)] and I?c(|s] coincide up to renaming of valid config¬ 
urations. So the reconfigurator together with an existing implementation of A 
gives us the abstracted analysis Va- The above equality is illustrated by Fig. 1. 
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Theorem 6. 

Vs G Stm,a : —>• G Abs,d G : I?a[s] d = Vl|a(s)] d 

Example 9. Consider the program Si from Example 1 with = {A A B, A A 
-^B, -^AAB}. We have calculated in Example 7 that I?^join|5'i]([xi->'T]) = ([xi-G 

1]). We now calculate Vl|Q:^^'f^,(S'i)]([xi—>'T]) (here ° 

([x^l]) 

6 Evaluation 

Recall that there are two ways to speed up lifted analyses: improving representa¬ 
tion and increasing abstraction. First, we will compare the performance of the 
two using an unoptimized lifted analysis as a baseline. Then, we demonstrate 
that abstraction may be used to turn previously infeasible analysis into feasible 
ones. Finally, we consider example scenarios that use projection and join and 
show that abstraction may be applied to an entire product line or when just 
analyzing a single method. 

For our experiments, we use an existing implementation of lifted data-flow 
analyses for Java Object-Oriented SPLs [5]. The implementation is based on 
SOOT’s intra-procedural data-flow analysis framework [20] for analyzing Java 
programs. It uses CIDE (Colored IDE) [16] to annotate statements using back¬ 
ground colors rather than #ifdef directives. Every feature is thus associated 
with a unique color. 

We will consider an unoptimized lifted intra-procedural analysis, known as 
A2 (from [5]), that uses jlK,/,]-tuples of analysis information, one analysis value 
per configuration. Also, we consider A3 (from [5]) which is the same analysis, but 
with improved representation via sharing of analysis-equivalent configurations 
using a high-performance bit vector library. Note that A2 corresponds to A in 
Fig. 2 and we will thus refer to it as A, while we will use S for the analysis with 
sharing (Vl3 in [5]). The performance of abstracted analyses depends on the size 
of tuples they work on. Therefore as variability abstractions, we have chosen 
Unjoin which joins together (confounds) information from all configurations down 
to just one abstracted analysis value, and E> prai^ joii, (where N = [K^]) which 

N/2^ N/2 

is a parallel composition of a projection of 1/2 (randomly selected) configurations 
and a join of the remaining 1/2 configurations. We abbreviate them as T>i and 
Ujv /2 in the following. We have chosen those variability abstractions because 
they represent the coarsest abstraction Vi that works on 1-sized tuples, and the 
medium abstraction I?;v /2 that works on Af/2-sized tuples. Any other abstraction 
will have a speed up anywhere between A (no abstraction), I5jv/2 (medium 
abstraction) and Vi (maximum abstraction). It thus quantifies the potential of 
abstractions. 

® The proof of this theorem is in App. F. 


^lx:=0] , ,^I#if(Z)x: = 

([xh^T]) ^ ([x^O]) ^ 
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Benchmark 

avg. 

F 

LOG 

max variability mth 


F 

LOG 

Prevayler 

N=1.3 

5 

8,000 

P’F’ .publisherO 

00 

II 

3 

10 

BerkelyDB 

N=1.6 

42 

84,000 

DBRimAct ion. main ( ) 

O 

II 

7 

165 

GPL 

N=3.9 

18 

1,350 

Vertex.displayO 

N=106 

9 

31 


Fig. 8. Characteristics of our three SPL benchmarks (average ^configurations 
in all methods in SPL, total ^features, and LOG) along with, for each SPL, its 
method with maximum variability (^configurations, local ^features, and LOG). 


ms ms 







Prevayler::publisherO 
N=8 


BerkeleyDB::main() 
N=40 


GPL::display0 
N=106 


Fig. 9. Analysis time for reaching definitions (above) and uninitialized variables 
(below): A (baseline) and S (sharing) vs. 'Dj ^/2 (medium abstraction) and Vi 
(maximum abstraction). 


For our experiment®, we have chosen two analyses: reaching definitions and 
uninitialized variables; and three SPL benchmarks [16]. Graph PL (GPL) is a 
small desktop application with intensive feature usage, Prevayler is a slightly 
larger product line with low feature usage, and BerkelyDB is a larger database 
library with moderate feature usage. Fig. 8 summarises relevant characteristics 
for each benchmark: the average number of valid configurations in all methods 
in the SPL, the total number of features in the entire SPL, the total number of 
lines of code (LOG). Also, for each SPL, the figure details information about the 
method with the highest variability (most configurations): its number of valid 
configurations, features, and lines of code. 

Performance. Fig. 9 shows the time it takes to run each of our three maximum 
variability methods, as a relative comparion between A (baseline) and S (sharing) 

® The implementation, benchmarks, and all results obtained from our experiments are 
available in the supplemental material submitted with this paper. 
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vs 'Dj^i /2 (medium abstraction) and (maximum abstraction). The experiments 
are executed on a 64-bit Intel® Core^'^ i5 CPU with 8 GB memory. All times are 
reported as averages over ten runs with the highest and lowest number removed. 
For each benchmark method, we give the speed up factor relative to the baseline 
(normalized with factor 1) and recall the number of configurations, N. 

Our experiment confirms previous results that sharing is indeed effective 
and especially so for larger values of N [5]. On our methods, it translates to 
speed ups (i.e., A vs S) anywhere between 3% faster (for N=8) and slightly 
more than twice as fast (for N=106). We also observe that abstraction is not 
surprisingly significantly faster than unabstracted analyses (i.e., T) vs A and 5); 
i.e., abstraction yields significant performance gains, especially for benchmarks 
with higher variability. For GPL with N=106, we see a dramatic 47 and 28 times 
speed up depending on the analysis (i.e., Vi vs A). Also, we note that increased 
abstraction is up to 26 times faster than improved representation (i.e., vs S). 
In general, it is obviously possible to combine the benefits from representation 
and abstraction to yield even more efficient analyses. 

From Infeasible to Feasible Analysis. Of course, for very large values of N, 
analyses may become impractically slow or infeasible. As an experiment, we took a 
large method (processFileO from BerkeleyDB) and kept adding unconstrained 
variability. For N=2^^=8,I92 configurations, the analysis A took 138 seconds. 
For N=2^‘*=I6,384, it ran more than ten minutes until it eventually produced 
an out-of-memory error. In contrast, variability abstraction Fi analyses the 
same high variability method in less than 8 ms (albeit less precisely). Hence, 
abstraction can not only speed up analyses, but also turn previously infeasible 
analyses feasible. 

Projection on Entire SPL. GPL is a family of classical graph applications 
with variability on its representation and algorithms. For instance, the features 
Directed and Undirected control whether or not graphs are directed; Weighted 
and Unweighted control whether or not the graphs are weighted; and, the features 
BFS and DFS control the search algorithm used (breadth-first search or depth- 
first search). It is common industrial practice, to ship products with a subset 
of configurations, and thereby functionality. Here, we may use projection to 
disable features BFS and Undirected, along with any features that only work 
on undirected graphs: (Connected, MSTKruskal, and MSTPrim for implementing 
connected components and minimum spanning trees algorithms) which can be 
obtained from GPL’s feature model, detailing such feature dependencies. With 
this projection (abstraction), the configuration space of GPL is reduced from 528 
to 370 valid configurations. This, in turn, cuts analysis time of reaching definitions 
in half (from 90ms to 49ms). For 123 out of 135 methods, the abstracted analysis 
computes the exact same analysis information. For larger product lines and 
projections, lots of time may be saved in this way. 

Join on One Method. Figure 10 shows a fragment extracted from BerkeleyDB’s 
mainO method with N=40 valid configurations. A local variable, doAction is 
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defined and initialized to zero, after which it is conditionally assigned three 
times in statements guarded by #ifdefs. (Actually, there are two more similar 
#ifdefs involving features Evictor and DeleteOp, but we have omitted those 
for brevity in the code fragment.) We can use a join abstraction of the reaching 
definitions analysis to compute what are the possible values (definitions) that 
reach the condition of the switch statement in line 12. An abstracted analysis 
would be able to determine that these are the assignments in lines 1, 3, 6, 8, and 
10 , by analyzing only one crudely over-approximated configuration instead of all 
(N=40) configurations. In general, by inspecting the structure of the code and 
the features used, we can tailor abstactions that can analyze individual methods 
much faster than analyzing all configurations. 


void main(. . 

) { 

1 

. . int 

doAction = 0; .. 

2 

#ifdef 

Cleaner 

3 

if (..) 

doAction = CLEAN; 

4 

#endif 


5 

#ifdef 

INCompresser 

6 

if (..) 

doAction = COMPRESS; 

7 

#endif 


8 

if (..) 

doAction = CHECKPOINT; 

9 

#ifdef 

Statistics 

10 

if (..) 

doAction = DBSTATS; 

11 

#endif 


12 

.. switch (doAction) { .. } .. 


} 

Fig. 10. Code fragment extracted from BerkeleyDB: :main() with N=40. 


7 Related Work 

Static analyses can be accelerated by devicing more efficient representations or 
by introducing abstraction. In family-based analysis for software product lines 
the representation improvements primarily rely on sharing state information for 
variants with analysis-equivalent information (which implies reducing redundant 
computation). This can optimize the analyses considerably [5,6,14]. However, in 
the worst case, the number of variants that a lifted analysis has to consider is still 
inherently exponential in the number of features, |F|. Thus with a large number 
of features lifted analyses may become impractical or even infeasible. In this 
work we have taken the alternate route of using abstraction. Our experiments 
show that abstraction introduces speed-ups independently of representation gains. 
Thus our results can be beneficially combined with efficient representations. 

An efficient implementation of lifted analysis formulated within the IFDS 
framework [18] for inter-procedural distributive environments was proposed in 
[4]. It uses binary decision diagrams to represent shared feature con¬ 
straints. The authors have found that the running time of analysing all variants 
in a family is close to the analysis of a single-program. In such case, further 
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benefit of applying abstraction, as presented in this paper, is unlikely to bring 
any significant improvement. However, notice that the method of is lim¬ 

ited only to distributive data-flow analysis encoded within the IFDS framework. 
Many analyses, including constant propagation, are not distributive and hence 
cannot be expressed in IFDS. Let alone static analyses that are not expressible 
as data-flow analyses (including type checking, model-checking, etc). 

The formal developments in this paper are based on variational abstract 
interpretation, a formal methodology for systematic derivation of lifted analyses 
for #ifdef-based product lines, proposed in [17]. The method is based on the 
calculational approach to abstract interpretation of Cousot[ll], applied and 
contextualized to product lines. In that work, Galois connections are not used for 
lifting, but only for derivation of single program analyses as shown in [11], so they 
are variability-unaware. Calculations are used to derive a directly operational 
abstraeted lifted analysis which is eorreet by construction. In the present paper, we 
assume that lifted analyses exist (possibly obtained using the methodology of [17]), 
and focus on abstracting variability using them. We devise an expressive calculus 
for specifying abstraction operators. Also, thanks to our tool, all abstractions 
specifiable in our calculus, are now automatically executable. 

A good collection of analyses that have been lifted manually is presented in 
the survey [19]. We should remark, that the join operation allows applying 
single program analyses to program families, even if with precision loss. In that 
sense, the our approach is the first ever method that can automatieally lift single 
program analyses to work on program families. Besides the family-based strategy, 
the survey [19] identifies a sampling strategy as a suitable way of analyzing product 
lines (see also [1]). In the sampling strategy only a random subset of products is 
analyzed. We remark that once the sample is selected, our projection operator 
Q,^roj used to realize the sampling strategy in a simultanous way by 

exploiting an existing family-based analysis. 

In fact, the agebraic specification framework of Sections allows specifying 
any analysis in the spectrum between a fully family-based analyses, and a single 
variant, produet-based, analysis. We can specify abstractions that select (sample) 
any subsets of configurations and then analyze this subset with selected choice 
of precision, either all variants precisely, like in sampling, or confounding some 
executions for efficiency. In this sense, we show how to design analyses placed 
anywhere in the design spectrum painted in [19]. Consider, the feature-based 
analysis strategy as an example. In this strategy an analysis explores the program 
code feature-by-feature (as opposed to configuration-by-configuration). Analyses 
following this strategy can now be systematically obtained using our abstractions, 
by projecting away (ignoring) all but one feature and running a single program 
analysis on the result. This is quite remarkable. It has been well recognized that 
designing such analyses is very difficult, yet now there exists a systematic way of 
doing that, so it is no longer an impenetrable art. 
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8 Conclusion 


We have defined variability-aware abstractions given as Galois connections, and 
used them to derive efiicient and correct-by-construction abstract analyses of 
program families. We have designed a calculus for the abstractions, and shown 
how abstractions specified in this language can be applied not only on analyses, 
but also on programs, obtaining a convenient implementation strategy of the 
abstractions in form of a source-to-source reconfigurator transformation. 

The reconfigurator transformation presently requires that the programming 
language is able to express sequential composition (e.g., in IMP) and join 
of statements (i.e., lub as in “U”) with respect to the analysis in question. It 
would be interesting to consider lifting those assumptions in future, and apply 
this method to more modeling and programming languages. 

We evaluated the method on three Java-based product lines. We found that 
the abstractions improve performance of analyses independently of improvements 
in the data representations used in the implementations of these analyses. This 
indicates that the proposed abstraction strategies will be instrumental in tackling 
error finding analysis in large configurable software systems, like the Linux kernel. 
Indeed we have developed these techniques with the intention of scaling error 
finding tools to such challenging cases in future. Besides this, we would like to 
experiment with applying these abstraction techniques to alternative quality 
assurance methods including model checking, and testing. 
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A Properties of Abstraction Operators 


We recall properties of Galois connections for completeness. 

7 

A pair (L, <l) {M, <m) is a Galois connection between complete lattices 

L and M iff a and 7 are total functions that satisfy: a{l) <m "m I <l "/{m) 
for alH G L, m G M. 

Some important properties of Galois connections [9] include: 1) 7 o a is 
extensive, i.e. I <l (7 o a){l) for all Z G L; 2) a o 7 is reductive, i.e. (a o 
'y)(m) <M rn for all m G M: 3) a is a complete join morphism (CJM), i.e. 

= UzeL '«(0 for all L'C L. 


Now we turn to proving theorems of Sect. 3.1. 

Proof (Thm. 1 ). Let d G and a G A“^ = A; recall that Q:i°™(K) is always 

a singleton. We have: 


Q:j°'"(d) E (a) 

(UfcGK^fc(a)) E (a) 

<;=^ \/k G K. TTkid) E a 

^ dEV°”(a) 


(by def. of 

(by def. of U) 
(by def. of 7!°“) 


□ 

Proof (Thm. 2). Let a G A'*^ and a' G y^e have: 

ap(d)Ed' 

Wk £K,k \= if. TTkid) E 7i'fc(d') (by def. of ccP™-’) 

yk G K,k \= (f. TTkia) E 7rfc(a') A Vfc G K, fc ^ A- '^fc(d) E T 

(by def. of T) 

^ dETr^d') (by def. of 7^7 

□ 


For sequential composition Galois connection properties follow directly from 
the definition and the standard results about compositions of Galois connections. 
Let’s consider the parallel composition: 

Proof (Thm. 3). To verify that this defines a Galois connection, we calculate: 


(by def. of oi 0 02 ) 


cti (g) a2{a) E a' 

Q;i(d) X a2(a)Qa' 

Q!i(d) E7r„i(K)(a') A 02 ( 0 ) E7ra2(K)(a') 

(by def. of df x dd, 7rai(K), and 7ra2(K)) 

dE7i(7rai(K)(aO) A dE72(7ra2(K)(a')) (by def. of Galois conn.) 

dE7i(7’'ai(K)(aO) n 72(7rQ2(K)(a')) (by def. of n) 

d E 7i G 72(0') (by def. of 71 0 72) 
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We now turn our attention to proving properties of the derived abstraction 
operators introduced in Sect. 3.2. Observe that all derived abstractions are Galois 
connections thanks to theorems of Sect. 3.1. 

We proceed to show that can be expressed using the basic abstractions. 

This will allow us to disregard it in further proofs, which are mostly done by 
structural induction on the structure of the abstractions. In this proof, it is 
convenient to name the configuration formulas of the abstract domain, so let 
{k[,... ,k'^} = indexed in the order of components in vectors indexed 

by Also, recall that o aP’'°l is another derived operator, 

which we use in this theorem. 

Proof (Thru. 4)- We first look into the expansion of and establish that 

the types of both sides are correct. By definition (equation (10)) the type of 
^fignore ^ xhe type of each in the right hand side of 

the equality is —>■ and consequently the type of the entire product in 

the left-hand-side is A* —>■ as required; cf. the definition of parallel 

composition for configuration sets. 

The proof proceeds by mathematical induction with the following hypothesis: 

• 0 <7") (a) = l\l=i UfeGK.feh M 


Base case. Consider a single a)))™ and let a G A^. We proceed by equational 
reasoning from left to right: 


air(a)= (aj°‘"oaP)°J)(a) 

(def. of od°™) 

= (riffcGKifehfe;} ^fc(a)^ 

(def. of aP™!) 

= (U{feGK|/c|=/c;} ’’’fc)®)) 

(def. of aj°“) 

Inductive step (again by equational reasoning from left to 

right): 

(ai7"®-- •««):)“)(«) = 

= ((^a- Ill=i UfeGK.fchfc; ^fc(a)) ® (“) 

(by IH) 

= ((^a- UUi UfeGK.fchfc; ^fc(a)) ® (^a- (UfcGK.fcM'+i^^(“)))) (“) 

(the base case above) 

= (^Aa. 7rfe(a)^ (a) 

(def. of 0; fc '_|_2 is a different formula from any of fc(s) 

— rii^i UfeGK,fc|=fc; 

(beta reduction) 


The above completes the inductive proof. The inductive hypothesis for i = n 
concludes the proof of correctness for expansion of 
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The proof for the expansion of is similar. The type of is by 

definition —> A'*^. The type of each of the factors in the right-hand-side 

is 7^°'” : —>■ A*^. Now, by definition of the product the type of the entire 

term is: A’^^i’-'-Anl —A*^ (since k[ are different formulea). 

The inductive hypothesis is {a" € A^^i’ 


n 

kGK 


7 rfc'(a") if fc ^ k'l for some I € l..f 
T otherwise 


Base case. 


y‘r" = yT ° r'°'” = '‘lIs")) 


= AS", n 


'Ky{a") if fc ^ 


fceK 


T 


otherwise 


(def. of projection) 
(composition) 


Inductive step. 

(7if »■-« 

= (Ar. (n 

\ VfcGK 

(n 






TT^{a") if fc ^ k[ for some I G l..i 


T 


otherwise 


7rfe.+i(a") iffc^fc'_^i 


T 


otherwise 


{a") (IH and the base case) 


= I Ad" ]J I iik\= k[ for some I G l..f -h 


kGK 


T 


otherwise 

/ 

(k'l formulas are not equivalent and (g) uses U) 


n 

kGK 


7 rfe'(a") if fc 1= for some 1 G l..i -I- 1 


T 


otherwise 


(beta reduction) 


Now, instantiate the inductive hypothesis for i = n, and observe that for any 
fc G K there exists a, k[ G 0 :^®"°'^®, such that fc ^ fc(, so the second case is never 
exercised and we end up concluding that: 




lom \ /—//\ fignore/—//\ 

TkL (« ) = 7 / [a ) 


□ 
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B Appendix: Proof of Soundness of Abstracted Analyses 


We denote with (*) the equation: 

ct{a) = 7rfe/(a(a)) 

fc'Ga(K) 

where a G and a : A* —>■ G Abs. 

Proposition 1. Ve G Exp,{a,j) G Ahs,d G A°‘^^'i’'> : aoA'\e\o"f{d) C V'a\e\d 
Proof. By induction on the structure of expressions. 


Case n: 


Case x: 


(a o A'|n] o 7)(d) 
= a(A'[n](7(d))) 

= a( n ”) 

= n ” 

= W4nj 


(by def. of o) 
(by def. of A in Fig. 2) 

(by helper Lemma 1 in App. C) 


{a o A'|x] o 7 )(d) 

= a(A[x](7(d))) 

= a( 7rfc(7(d))(x)) 

= n ^k'{a{-/{d))){x) 

t J| 7rfe/(d)(x) 

fc'Ga(KT^) 

= X>'a|xp 


(by def. of o) 
(by def. of A' in Fig. 2) 

(by def. of (*)) 

(007 is reductive) 
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Case Co © ei: 


(by def. of and ©) 
(by def. of (*)) 


(ao^'leo© ei] 0 7)(d) 

= a(^'|eo © ei]( 7 (d))) (by def. of o) 

= “( n ’^fc(“^'[eo] 7 (d)) © 7 rfc(y^'|ei] 7 (d))) (by def. of A' in Fig. 2) 

= a( 7rfc(y^'|eol7(d)®^'|ei]7(d))) 

= n T^k'{a{A'leoh(d)®A'lei]-/(d))) 

k'Goi(K^) 

t J| 7rfc/(a(^'|eol7(d))®a(yl'|ei]7(d))) 

fc^Ga(K^) 

(by helper Lemma 3 in App. C) 
E P 7 rfc-(X>E[eoP®iC>Eleip) (by IH, twice) 

k'Ga(K^) 

= P 7 rfc/(X>'aIeop) © 7 rfe/(I?Eleip) (by def. of and ®) 

k'Goi{K^) 

= V'aleo © eip 

Proposition 2. Vs G Stm, ( 0 , 7 ) G Abs,d G : ao^|s] 07 (d) t I?a[s] d 


Proof. By induction on the structure of statements. First, we define (i[xG>u] = 
Ilk'&aiK^)^k'(d)[x ^ TTk'(v)], for all d G and v G Const“('^'^). Thus, 

d[xG>u] is a tuple that is as d except that in each component of d the variable x 
is mapped to the corresponding component of the tuple v. 


Case skip: 


(a o Vl|skip] o 7 )(d) 
= a(Vl|skip]( 7 (d))) 
= a(7(d)) 
t d 

= Dapkipp 


(by def. of o) 
(by def. of A in Fig. 2) 
(007 is reductive) 
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Case X := e: 


{a o y^|x : = e] o 'y){d) 

= a( n '^kh(d))[x^ TTkiA'lejjid))]) 
= a( n ^k{l(d)[x^AA'lej-f(d)])) 

= 7rfe/(a(7(d)[xi-^^'|e]7(d)])) 

fc'GQ((K-0) 

= n ^k'{a{'y(d))[x^^a{A'le]-/(d))]) 

k'G<y(K^) 


(by def. of A in Fig. 2) 
(by def. of i-b-) 


(by def. of (*)) 


(by helper Lemma 4 in App. C) 
t TTk'{d[xi-^TAale-Jd)]) (IH, and a o 7 is reductive) 

k'Ga{K^) 


= n T^k'{d)[x^ TTk’iV'alejd)] (by def. of 

/c'Ga(K^) 

= Valx := ejd 


Case if e then Sg else Si: 


(a o A|if e then Sg else Si] o 'y){d) 
= a(A|if e then Sg else si]( 7 ((i))) 
= a(A|sg]7(d) U A|si]7(d)) 

= a(A|sg]7(d)) LJ a(A|si]7(d)) 
tValsojd U I?a|sip 
= T>a\lf e then sg else si] d 


(by def. of o) 
(by def. of A in Fig. 2) 
(by a is a CJM) 
(by IH, twice) 
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Case #if ( 9 ) s: 


(aoyl|#if (0) s]o7)((i) 

= a{Al#if { 9 ) s]( 7 (d))) 

/ TT f ifk\=9 

= “( IM 

fcGK^ Wfe( 7 W) 


(by def. of o) 
(by def. of A in Fig. 2 ) 
if k' ^9 


^ n 

k'£a(K^) 


^ n 

k'^a{K.^) 


iik^ 9 

TTk'{a{Als]-f(d))) 

7 '‘fc'(a( 7 (d))) U 7 rfc/(a( 7 l|s] 7 ((i))) if sat(fc'A 0 ) A sat(fc'A^ 0 ) 

7 rfc'(a( 7 (^))) if A:' 1 = 

(by helper Lemma 2 in App. C) 

TTk'i'Dalsjd) if k '9 

TTk'id) LI Trk'iValsJd) if sat(fc'A 6 l) A sat(/c'A^ 0 ) 


TTk'id) 
= ( 0 ) s] d 


if fc' h ^0 

(by IH, and a o 7 is reductive) 


Case while e do s: We introduce a higher-order Galois connection between 
A*’'' —)• and defined as: 


a^{^) = Ad. a(^>(7(d))), for ^ : A’^’^ A'^'^ 

7^(F) = Aa.7(F(a(a))), for W : ^ 


Let / = A^. Aa. aU <?(Al|s]a) be the functional in Al|while e do s]. We 
calculate an over-approximation of 0/0 7 ->., denoted as F, and then apply 
the fixed point transfer (FPT) theorem [8] on the result. Given a monotone 
function 4 >', we have: 


(q!_> 0/0 7_>)^' 

= a_>(/(Aa. 7(^'(a(a))))) (by def. of o and 7_>) 

= a_>(Aa. aU7(<?'(a(Al|s]o)))) (by def. of / and / 3 -reduction) 

= Ad. Q!(7(d)LJ7(<?'(a(Al|s]7(d)))) (by def. of «_>) 

= Ad. a(7(d))LJQ:(7(^'(a(Al|s]7(d))))) (by a is a GJM) 

t Ad. dU <l>'{'Dals}d) (by IH; and a o 7 is reductive, twice) 

= f¥ 
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Thus, we obtain F = A^'. Ad. dUF{Va\s\d). 
F is also monotone. We now have: 

Since F and T>a are monotone, 

{a o Al|while e do s] o 'y){d) 


= a(lfp/(7(rf))) 

(by def. of A in Fig. 2) 

= a_,(lfp/)(d) 

(by def. of a_>) 

t (IfpF)d (by fixed point transfer (FPT) theorem) 

= I?Q, [while e do s]d 

(by def. of V in Fig. 5) 

C Appendix: Helper Lemmas 

Lemma 1. Va G Abs : aiUkeK^) = Tlfe'eaW 
Proof. By induction on the structure of a. 

Case 

n 



fceK 


= (UfcgK^) 

(by def. of 

= n ^ 

(by def. of aj°“(K)) 



Case aP^j; 




k^K 


= n ^ 

(by def. of qP™!) 



= Y[ n 

(by def. of aP"'°j(K)) 

fc'GaP^^K) 


Case «! (g) a 2 - 


ai (8 Q; 2 (]^ n) 


feeK 


= ai(Il n) X a2(]^ n) 

(by def. of ai ® 0 : 2 ) 

keK keK 


= ( n ^ ( n 

(by IH, twice) 

k'^a.i(K) k'Ga2(^) 


= l[ n 

(by def. of ^ x ^) 

k'^aiUa2{K) 


= ll n 

(by def. of ai 0 a 2 (K)) 

/c^GQi0a2(K) 
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CQ-SG Ct2 ^ 


^2 o «i(n 

fceK 

= 0 i 2 {ai{W_ n)) 
feeK 

= Oi 2 { Jl n) 

k'^OL\ (K) 

= n ^ 

/i:"Ga2{ai(K;)) 

= n ^ 

k" ^ct2oa.i (K) 


(by def. of o) 
(by IH) 
(by IH) 

(by def. of 02 o ai(IK)) 


Lemma 2. 


Va G Abs, 'ipjO £ FeatExp, ai, 02 G 

rifceK 


7rfe(ai) 

ifk^Q 


T^kfaf) 

if k^0 



' 7!'fe'(a(aT)) 

ifk'^e 

[fc'eQ(K) ^ 

7rfe/(a(aT)) U 7rfc/(Q;(a^)) 

if sat{k'A9) A sat{k'A^O) 


, 7rfe'(a(a^)) 

if k' h -^0 


Proof. By induction on the structure of a. 
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Case 


vJoin 


n 


7 rfc(ai) if k\= 9 

- n I / if A: h ^ . 

' UfeeK} ^k(af) if V kGK k \= 0 

_ ^ ^ U{fe6K|fc|=e} ^fc(®l) LI U{fc6K|fch^e} ^fc(®2) 

. UfeeK '^kio- 2 ) 


(by def. of aj°'") 


if sat {\J,^^kA9) A sat(V,^^A:A-0) 

if VfceK^ U 


(by def. of tt^ and U) 


E < 


f UfeeK'^fe(®i) if VfceK^ U ^ 
UfeeK’"fe(^)L UfeeK 


if sat {\J,^^kA9) A sat(V,^^A:A-0) 
if VfceK fc 1= 


I UfeeK’’’fe(®2) 

(by def. of TTfc and U) 

Q;i°'"(oi) if VfceK^ U ^ 

= ( <( Q;j°‘"(QT) U Q:j°“(o^) if sat {\/^^^kA9) A sat(V,gKA;A^6l) ) 
ai°-(a2) ifVfcgKfch-0 

(by def. of aj°“) 


We provide an example confirming that the above relation is not equality. Let 
K = {A A B,A A ^B}, af = ([x i—)■ 2], [x i—> 4]), and 02 = ([x i—>■ 6], [x i—>■ 2]). 
[ 7rfe(ad) if A: ^ B 

For a = nt.ciir \ > we have a = ([x i-A 21, [x i-A 21). Then 

Ufe(a^) ifA:^B 

Q,join(^) = ([ 2 ; 1 -). 2]). On the other hand, ai°‘"(ai) U ai°“(a 2 ) = ([x i-A T]). 
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Case 


vP^oj 


n 


n 


f TTkiai) if k\= e 

1 T^kiM) iik^ 9 

17 rfc(aT) ifk \=0 

T^k{^) if k^ 9 


= n 

= n 

fc'eaP'°'i(K) 

E n 

fc'eaP'°'i(K) 


f 7 ^fc(a^‘'°'’(oT)) a k\= 9 
[ 7rfc(aP''°'’(^)) iik^9 
I' 7 rfe/(Q:P"'°J(aT)) if k' \= 9 

[TTfeK^rH^)) ^ik'^9 

^fc<(aP™j(ar)) 

^fc.(aP™j(^))U^fc-(aP™j(a^)) 


TTk' (a 


rH^)) 


(by def. of a'^°^) 
(by def. of TTfc and cy.'^°^) 
(by def. of 


if k' ^9 

if sat(fc'A 6 l) A sat(fc'A^ 0 ) 
if k' \= ^9 

(by def. of t and U) 
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Case «! 0 a 2 : 



if k 1=0 
if k ^0 
if k 1=0 
if k^ 0 ^ 


) 



7rfe(ai) 

7!‘fe(a^) 


if k 1=0 
if k^ 0 ^ 

(by def. of Oi 0 02) 


^ n 

k'Gcxi (I 


X n 

k'Ga2(. 


7rfc/(ai(ai)) if k'j= 0 

7rfc/(ai(aY)) U tt^/( 01(02)) if sat (A:'A 0) Asat(A:'A^0) 
7rfc/(ai(a^)) if k'i= =0 

TTfc/(02(01)) if fc'^ 0 

TTfc'(02(01)) U TTfc'(02(02)) if sat(A:'A0) A sat(fc'A^0) 
7rfc/(02(Q^)) if k' 1 = =0 

(by IH, twice) 


= n 

/i:'GaiUa2(K) 


' TTfc/(ai(oi) X 02(01)) if fc' 1= 0 

7 i'fe'((oi(al) X 02(0^))) U 7 rfc/((ai(o^) x 02(^))) 

if sat(fc'A0) A sat(fc'A^0) 

^ 7rfe/(ai(a^) x 02(0^)) if k' |= =0 


= n 

/i:'Gai0a2(K) 


(by def. of ^ x X2) 

7rfc/(oi (g) 02(0^)) if fc'^ 0 

7rfc'(oi (g 02(01)) U 7rfc/(oi g 02(02)) if sat(A:'A0) A sat(A:'A^0) 

7rfc/(oi g 02(^)) ifk'\==0 

(by def. of ST x ST, and oi g 02) 
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C&SG Ot‘2 O 

[ 7 rfc(aT) iik \=9 

q; 2 o ai( 

44l7rfc(a2) iik\^9 


e« 2( n 

A:' Gq;i (1 


=« 2 (( n 

fc'eai(K) 


=« 2 ( n 

fc'eai(K) 


E n 

k" ^OC 2 {OLl{ 


)) 


7 rfe/(ai(ai)) if fc' ^ 0 

TTfe/(«!(of)) U TTfc/(0:1(02)) if sat(fc'A 0 ) A sat(fc'A^ 0 ) ) 
7 i'fe'(ai(o^)) if fc' 1 = 

(by IH) 

7 rfe/(ai(arr)) if k' ^9 

7 rfe'(ai(o^)) if fc' h 
(by def. of U and ^) 
f 7 rfc'(oi(aT)) if k' ^ 

1 ) 1 7 rfc'(Q;i(a^)) if k' |= ^9 
(by 02 is CJM) 

TTfc"(02(01 (^))) if k” ^ 9 

TTfc"(02(01(0!))) LI TTfe/(02(01 (02))) if sat{k"f\ 9 ) A sat(A:"A^ 0 ) 

TTfc"(02(01 (^))) if k” ^ ^9 


[' 7 rfc/(ai(oi)) if fc'(= 0 j 

[ TTfc/(01(02)) if fc'^ 0 fc'eQi(K) I 

7rfc'(«i(^)) if h , , T-r 

) U 02 ( 1 [ 

7 rfc'(oi(o 2 )) if fc'^ 61 


u n 

A;^'GQ: 2 (cki(K)) 


= n 

k"^Oi 20 O'i (K) 


' TTfc//( 02 ( 01 ( 01 ))) if k” ^ 9 

TTfc" ( 02 ( 01 ( 01 ))) U 7rfc/(a2(oi(^))) if sat{k"f\9) A sat(fc"A^6l) 

, TTfc//( 02 ( 01 ( 0 !))) if fc" ^ -^9 

(by IH; twice) 

7 !‘fc"(02 o oi(^)) if k" ^ 9 

T^k"{ci 2 o C(i{ai) U 02 o 01 ( 02 )) if sat(fc'A0) A sat(fc'A^0) 

7 rfc/(a2 o oi(a!)) if k" ^ ^9 

(by def. of 02 o oi) 


Lemma 3 . Vo S Abs, vi,V2 G Const^ : a{vi 0 02) t o(vi) © o(t'2) 
Proof. By induction on the structure of a. 

Case 


Q:i°‘"(oi © V 2 ) 

= UkeK'^kivi © v!) 

= UfeeK (7’'fe(^) ® T^ki^)) 

E (UfceK^fc(fE)) ® (UfceK7rfc(l^)) 
= aj°“(ur) © aj°“(u!) 


(by def. of ai°'") 
(by def. of and ©) 
(by def. of [J and ©) 
(by def. of ai°'") 
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We provide an example confirming that the above relation is not equality. Let 
nr = (5, 2), nr = (2,5), and © = +. Then aj°“((5,2)©(2,5)) = aj“"((7, 7)) = 
7. On the other hand, aj“"((5, 2)) = T, aj°“((2, 5)) = T, and T+T = T. 
Case aP^j; 

©^) 

= 7rfe(n7 © nr) 

= (7rfe(tT) © 7rfe(nr)) 

= ( n ® ( n 

{/cGIKI fc|—(/?} {/cGIKI fc|—(/?} 

= aP™j(nr) § aP™j(nr) 

Case «! © 

ax © a 2 {vi © nT) 

= ci;i(nr©nr) X a 2 (o © 

t (Q;i(nr) © ai(n2)) x (a2{vi) © ci;2(t^)) 

= (ai(o) X a2(o)) © (ai(w) x a2(w)) 

= «! © a 2 (nr) © «! © a2{v^) 

C&S© Q !2 ^ 

<22 o Q;i(n7 © nr) 

= Q;2(ai(hr © hr)) (by def. of o) 

E <22 (<21 (hi) © Q;i(hr)) (by IH) 

E <22(<2i(hr)) © Q;2(<2i(hr)) (by IH) 

= q; 2 o ai(hr) © a2 o <2i(hr) (by def. of a2 o <2i) 

We define d[x©>h] to mean a tuple that is as a except that in each its 
component the variable x is mapped to the corresponding component of the tuple 

V. 

Lemma 4. Va G Abs,a G A^’^jh G Const^ : a(a[xG>h]) = a(d)[xG>a(h)] 

Proof. By induction on the structure of a. 


(by def. of ax © q; 2 ) 
(by IH, twice) 
(by def. of x and ©) 
(by def. of ax © ^ 2 ) 


(by def. of 

(by def. of and ©) 
(by def. of H and ©) 
(by def. of ctb™-’) 
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Case 

= UfceK^fc(a[x^^v]) 

= UfceK (7r/c(a)[x ^ 7rfc(w)]) 

= (UfceK’^fc(a))[x ^ UfceK^fc(^)] 

= Q:j°“(o)[x !-)■ 

Case aP^j; 

= JJ 7rfe(a[xi-4iJ]) 

= (7rfe(a)[x i-> 7rfc(z))]) 

= ( n 7Pfe(a))[x^4 J| TTk{v)] 

= ap(a)[x^ap(T;)] 

Case «! ® a 2 - 

Oil ® Q;2(a[xi-4w]) 

= ai(a[xi-4w]) X a2(a[xi-4v]) 

= ai(o)[xi-4Q;i(w)] X a2(a) [x'-^Q;2(w)] 

= (ai(a) X a 2 (a))[xi-^ai(iJ) x q;2(^^)] 

= «! 0 a2{a)[xi-^ai 0 q;2(w)] 

Case a 2 o ai: 

a2 o ai(o[xi-4t']) 

= a2(ai(a[xi-4u])) 

= a2(ai(a)[xi-4ai(v)]) 

= a2(ai(a))[xi-^a2(ai(w))] 

= a2 o Q;i(a)[xi-4a2 o ai(v)] 


(by def. of 

(by def. of and i-b) 

(by def. of [J and !->■) 

(by def. of 

(by def. of aP’^°^) 
(by def. of and i-b) 

(by def. of and i-b-) 

(by def. of aP’^°^) 


(by def. of oi 0 02 ) 
(by IH, twice) 
(by def. of x and M-) 
(by def. of oi 0 02 ) 


(by def. of a 2 o ai) 
(by IH) 
(by IH) 
(by def. of a 2 o ai) 


D Appendix: Monotonicity of Abstracted Analyses 

Lemma 5 (P'ale] is monotone). 

Ve G Exp, a G Abs,d,d' G d Q d' P'alejd t I?'Q,|e](i' 

Proof. Let e, a, and d O d' be given. We proceed by structural induction on e. 
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Case n: 


Case x: 


V'alnjd= n = V'alnjd' 

k'^a{K-tp) 


P'alxjd^ 7rfe/(d)(x) 

n TTk'{d'){x) 

k'Goi{K^) 

= ^„[xK 

Case eo © ei: 

'D'aleo © eip 

= TTk'(V'aleold)®TTk'(V'aleild) 

k'Ga{K^) 

E n ^fc'(^aIeoK)®^fc'(^a[eiK) 

k'Ga{K-ti,) 

= 'D'aleo © eijd' 


(by def. of V'a) 
(by dtj) 
(by def. of V'a) 


(by def. of V'a) 
(by IH; and d Q d') 
(by def. of V'a) 


Lemma 6 (I?q,|s] is monotone). 

Vs G Stm,a G Abs,d,d' G d t= d' I?Q|s]d E 


Proof. Let s, a, and d E d' be given. We proceed by structural induction on s. 

Case skip: 

I?a|skip]d = d E d' = I?a|skip]d' (by def. of Va) 

Case X := e: 

Val^ := e]d 

= n (7rfc/(d))[x i-G 7rfe/(©>Eleld)] (by def. of ©>„) 

E (7rfc'(d'))[x i-G 7rfc/(I?'Q[e]d')] (by d E d'and Lemma 5) 

k'Ga(K^) 

= I?q|x := e]d' (by def. of Va) 

Case sq } Si: 

Valso ; Si]d 

= l^alsijiValsojd) (by def. of Va) 

E I?Q|si](I?Q|so]d') (by IH, twice; and d E d') 

= Valso ; Si]d' (by def. of Va) 
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Case if e then sg else si: 


Hclif e then sq else Sijci 
= X>aIsopUX>a|sip 

E PalsoRUP^IsiK 

= I?Q,|if e then Sq else Sijii' 

Case #if (0) s: 


(by def. of Va) 
(by IH, twice; and d t d') 
(by def. of Hq) 


X>a|#if ( 9 ) sp 

( TTk'{T>alsjd) iik'\=e 

= I TTk'{d)U'Kk'{T>a\s\d) if sat(fc'A6l) A sat(A:'A^6*) 

(by def. of Va) 

(TTk'{'Dals\d') if /c' 1= 6> 

— n \'^k'{d')U'Kk'{'Da\s\d') if sat(fc'A6l) A sat(fc'A^0) 

(by IH, and dt= d') 

= I?Q,|#if {6) sjd' (by def. of Hq) 

Case while e do s: Let / = M>. Xd. dLi <P{T>alsld) be the functional in the rule 
for while e do s. First we prove that applying the functional / to a monotone 
function <l> yields a monotone function. Thus, we obtain that the functional 
/ operates over the complete lattice of monotone functions. Let dtd' and a 
monotone function <P be given. We have: 


imd 

= dLJ^(I?a|sp) 
t d'LJ^(P„|sK) 

= {fm 


(by def. of /) 
(by IH, monotonicity of (P, and dtd') 
(by def. of /) 


Second we prove that the functional / itself is monotone, which guarantees 
that the while rule is well defined by Tarski’s fixed point theorem. We extend 
the operator C to operate over tuples of functions: f'Og = '^x.f(x)'Og{x). Let 
monotone functions <P and (P' be given and <PL1<P'. 

= Xd. d U <P{T)alsld) (by def. of /) 

t Xd. d U (p'(Val.sld) (by def. of t, and <PQ<P') 

= F<P' (by def. of /) 
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Since the least fixed point is an element of the complete lattice of monotone 
functions, it is itself monotone. Given dQd', we have: 


[while e do sjd = (lfp/)d t (lfp/)d' = [while e do s]d' 
which concludes this case. 

E Appendix: Abstracted Data-flow Equations 

The complete list of data-flow equations for abstracted constant propagation: 




Iwhile^ e do 

= Iwhile* e do U 


if k' 1= 9 


Vfc' g a(K,^) : 7rj,,(|#if^ {9) s'^ 0 ]^) ^ Try{l#il^ (9) U (|s't)|^) if sat(/c'Ae) Asat(fc'A^e) 

'ik' e a{K^): tt,./— 7r,,/(|#if^ (9) if (k' A 9 is sat) 

We can derive data-flow equations for expressions as well, but for brevity we 
refer directly to I^'ale] function. 

Theorem 7 (Soundness of Abstracted Data-Flow Equations). For all 

s G Stm and a € Abs, such that |s^]fl and [s^]^ satisfy the data-flow equations 
in Fig. 6, it holds: 



a 

out 


Proof. The proof is by structural induction on s^. 


Case skip^: 


X>a[skip^]([skip^]i^) 

= [skip^f^ 

= Iskip^l^ 


(by def. of Da) 
(by def. of and [-J^) 
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Case X : = 


e: 


V4x :=' e'»](Ix :=' 

= n ^ TTfcK^alellx :=^ 

k'Ga(K^) 

(by def. of Va) 

= n ■■=' (by def. of I-l|y and [-1^) 


Case Sg“ 


s 


b. 

1 • 


■/ 

= V4sn{v44msi° ■/ //£) 
= V4s{^j{v44^{i4x)) 

t p4s!1(I4i^) 

= v^si^iisiX) 

E 

= (I4“ 


(by def. of T>a) 
(by def. of |-l|y and hl^) 
(by IH) 

(by def. of |-l|y and hl^) 
(by IH) 

(by def. of |-l|y and hl^) 


Case if^ e then Sq° else s{^: 


e then Sg“ else s^^](|if^ e then Sq° 
= ^^cIso^KIif^ e then Sg° else LJ 

25alsi'l(|if^ e then Sg° else 

= 25441(14“!) E Pol/i1(l/i1(y) 

Ei4l^ui4i^ 

= |if^ e then Sq° else 4l! 


else 4!) 

(by def. of T>a) 
(by def. of |-l^, |-l^) 
(by IH, twice) 
(by def. of I-l(l, I-l^) 
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Case #if^ (6) s^°: 

P4#if^ ( 0 ) /«](i#if' ( 0 ) 

■ TTfcK^als^idttif" ( 0 ) 5^14) if fc' h 0 

7rfc/(|#if^ (0) U 7rfc/(P„|d«](I#if'^ ( 0 ) ^“1“)) if sat(A:'A6») Asat(fc'A^6») 


n 

fc'ea(K^) 


n 


TTfc/dttif'^ ( 0 ) d«]4 U TTfc/(Pals' 


fc'Ga(K^) ( 0 ) 


■^fc'ds'i^) 


if k' h --0 
(by def. of Pq) 

if fc' h ^ 

d“l^)) if sat(A:'A0) Asat(fc'A^0) 

if k' h -^0 

(by def. of I-l(^, I-l^) 

if A:' h 


n 

fc'6«(Kv.) I (g,) g4ja) 


= |#if^ (0) 


d) s^»];^)U^fcdrd^) ifsat(fc'A0)Asat(fc'A-0) 

if k' h -^d 

(by IH) 

(by def. of |-1^, |-1^) 


Case while^ e do 4: Let / = A<?. Ad. dU ^(Palsjd) be the functional in the 
rule for while e do s. We first prove by inner induction on n, that: 


/”(i)dwhile^ e do LJ [s^d^) £ [while^ e do s'^dc 


(14) 


for all n > 0, where _L = Ad. _L. The base case for n = 0 is straightforward. 
For the inductive case n = A: + 1, we assume that: 

/'=(i)dwhile^ e do s^dy^ ^ [s^d^) E [while'^ e do s^d^ 

Then we have: 

/'=+dI)dwhile^ e do s^di^ E Is^d^) 

= (by def. of 1-1(1, 1-1^) 

=/(/dl))ds^di^) (by def. of 4+d 

= [s^di^ U /dI)(PaIs^dds'”l)) (by def. of /) 

E [s^d(^ E /dl) (Is^d^) (by outer IH, monotonicity of /dl)) 

E [s^d(^ U /dl) ([while^ e do s^d(^ ^ [s^d^) 

(by monotonicity of /*(-L)) 
E [s^dyy LJ |while^ e do s^d^ (by inner IH) 

= [while^ e do s^d^ (by def. of [-1(1, [-1^) 
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Finally, we have: 


I?Q,|while^ e do s^“](|while^ e do 

= (lfp/)(Iwhile^ e do s^“]^) (by def. of V^) 

= (Ad. Ui/*(_L)d)(|while^ e do (by Kleene’s fixed point theorem) 

= LJi/*(_L)(|while^ e do (/3-reduction) 

E U,/*(-L)(Iwhile^ e do U [s^i^) (by monotonicity of /*(i)) 

E [while^ e do (by Eq. (14)) 


F Appendix: Proof that X>a|s] coincides with A|q:(s)] 


Proof. By induction on the structure of a G Abs and s G Stm. Apart from the 
#if-statement, for all other statements the proof is immediate from definitions 
of Va, A, and a(s). 

Let us consider the case of #if (0) s. 


Case 


[9) s]d (set of feat, is F, set of configs. is K^) 

I?Q,joi„|sld if 1= 0 

= ^ dUX>„ioi„|sp if sat(\/,g^^A:A0) A sat(\/,g^^fcA^0) (by def. of V^) 

= <1 dUA|a)°7(s)p if sat(V,^K^A:A0) A sat(\/,^^^fcA^0) (by IH) 

A|#if (Z) Q:)“f (s)p if y k^9 


= { A|#if (Z) lub(a)P(s),skip)]d if sat(V,^,^^A;A0) Asat(V,^^^fcA^0) 
A|#if i^Z) a)P(s)p if k[=^0 


(by def. of A] renaming: set of feat, is {Z}, set of configs. is {Z}) 
= Al|a'j 2 ”(#if (0) s)}d (by def. of A and O/™ 


(by def. of A and (#if (0) s)) 
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Case aP^j; 


X>c, proj |#if (6») sjd 

7rfe(X> 

I 

n 


n 

{fceK^|fc|=v3} 

n 


(set of feat, is F, set of configs. is K^) 
sJd) if fc ^ 0 

TTkid) U 7rfe(I?^proj |s]ci) if sat(A:A6l) A sat(fcA^0) 
TTk{d) if fc 1= ^6* 

(by def. of Va) 
(since fc is a valuation) 


(by IH) 


7rfc(I?c,p™''W'^) iik\=0 
TTkid) if fc ^ 0 

■^fc(:4[aP™l(s)p) iffch^ 

TTkid) if fc ^ 0 

= :4I#if iO) ap(s)p 
(by def. of A', renaming: set of feat, is F, set of configs. is {fc G | fc \= (f}) 
= ^|aP‘'°'’(#if (0) s)](i (by def. of A and Q:P''°j(#if (0) s)) 
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Case «! 0 a 2 - 


n 

fc'eQ 2 (K^) 


2^01002 I#if {^) sKc^) (set of feat, is F, set of configs. is K^) 

r 7rfc/(X>ai0a2 IsP) iik' '^e 

= < 7rfc/((i) U 7rfe/(I>„i0a2lsp) if sat(fc'A0) A sat(A:'A^0) 

'^'"“^0“2(*^") [TTfcKd) iffc'h^0 

(by def. of Va) 

( 7rfe/(X>„Js]7r„j(K^)((i)) ii k' 9 

= n < 7rfe/(7r„^(K^)(d))U7rfc'(2?aiIsl7rai(K^)(d))ifsat(A:'A6») Asat(fc'A^6») 

k eai(K^) y ^ 

( 7rfe/(X>„2lspa2(K^)(^)) if fc' h ^ 

X n < 7rfe/(7r„2(K^)((i)) U7rfc/(X>a2lspa2(K^)(^)) if sat(A:'A6») Asat(fc'A^6») 
k ea2(K^) y y ^ _^g 

(by def. of 7r„^(K^), TTa^iK^) and ai (g) 02 ) 

r 7rfe/(^|ai(s)]7r„^(K^)(fi)) if A:' ^ 6» 

= n ] ^k'{^ra^{K^)(d)) U 7rfc/(Al|ai(s)]7r„^(K^)(d)) if sat(fc'A6l) A sat(A:'A^6l) 

k eai(K^) y ^ ^g 

( 7rfe/(Al|a2(s)l7ra2(K^)(d)) if A:' h 

X n < 7rfe/(7r„,(K^)(d)) U7rfc/(Al|a2(s)]7r„2(K^)(^)) if sat(A;'A6<) Asat(fc'A^6») 
k ea2(K^) y 7rfe/(7r„,(K^)(d)) if k' h ^6* 

(by IH on a) 

Feii^) I' ^f(’^c.ak^)(^)) if ^ ^ 

tt f 7r^(“4I^(s> ^)Pa2(K^)(^)) if fc' h ^(^) 


n 

fc'ea2(K.V’) 


Fea2(K^) I' ^f(’^«2(k^)(^)) if k' ^ ^ 2 ( 0 ) 

(by def. oT, 5^; renaming: to oi ® q; 2 (F), oi ® q;2(IKv’)> (*)) 

= ^|ai(#if (6») s)]7r„^(K^)(d) x Al|a 2 (#if {9) s)]7r„,(K^)(d)^ 

(by def. of A, ai, and 02 ) 

J Al|#if (ai(t*) V a 2 (^^)) ai(s, if ai(s, 0) = 02 ( 5 ,6>) 

\Al|ai(#if {9) s);a 2 (#if {9) s)] otherwise 

(by def. of A, al, and 5^) 
= ^|q;i (g) Q; 2 (#if {9) s)](d) (by def. of oi (g) 0 : 2 (#if {9) s)) 
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(*) Note that k' is a renamed configuration of k'. The second case sat(fc' A 
9) A sat(A:' A ^9) has collapsed into the first case when k' |= aT(0) and 
ai{s,9) = lub{ai{s), skip) in the equation obtained after the renaming. 
Case a2 o ap. 


(^) sl{d) (set of feat, is F, set of configs. is 

( 7rfe//(X>„2oaiIsp) if k" \= 9 

= < Trk"{d) U TTk"{'Da 2 oails]d) if sat(fc"A0) A sat(fc"A^6l) 

(by def. of Va) 

( T:k"{A{a2 o q;i(s)P) if k” \= 9 

= < 7rfe//((i) U 7rfc"(^|a2 o Q;i(s)](i) if sat(A:"A0) A sat(fc"A^0) 

."ea20.AK.) iik"^^9 

(by IH on s) 

r 7r^(^|a^(^(s,6>),al(6»))p) if fc" |= a^(al(6»)) 

F^ea2oaAK^) I if ^ ^ a^(al(0)) 

(by def. of a, renaming: to 02 o ai(F), 02 o ai(Kv’)> (**)) 
= ^|#if (oi2{ai{9))) oi:2{^{s,9),ai{9))\d (by def. of A) 

= ^|q ;2 o ai(#if {9) s)]((i) (by def. of a 2 o Q;i(#if {9) s)) 


k" ^a.200ci 


k"^Oi20OLi{K^) 


(**) Note that k" is a renamed configuration of fc", and k" is a valuation 
over a 2 o ai(F). The second case sat(fc" A 0) A sat(A:" A -^9) has collapsed 
into the first case when k” \= a 2 (QT(^*)) and qT(s,6 *) or 7x2{ai{s, 9),ai(9)) is 
transformed into lub statement. 
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